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Input to IPng Engineering Considerations 
Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document was submitted to the IETF IPng area in response to RFC 
1550. Publication of this document does not imply acceptance by the 
IPng area of any ideas expressed within. Comments should be 
submitted to the big-internet@munnari.oz.au mailing list. 


Summary 


This white paper expresses some personal opinions on IPng engineering 
considerations, based on experience with DECnet Phase V transition. 
It suggests breaking down the IPng decisions and transition tasks 
into smaller parts so they can be tackled early by the relevant 
experts. 


Timescales 


In order to allow key decisions to be taken early, I would like to 
see IPng decisions and timescales broken down into into smaller 
parts, for example: 


- address structure and allocation mechanism 

- name service changes 

- host software and programming interface changes 
- routing protocol changes 


Although interrelated, not all details need to be defined by the same 
date. Identify which decisions will be hard to change and which can 
be allowed to evolve. All changes should be worked on in parallel, 
but the above list indicates a feeling for urgency of a decision. 

Our experience has been that administrative changes (as may be 
required for addressing changes) need the greatest elapse time for 
implementation, whereas routing protocol changes need the least. 
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I would like to see an early decision on address structure and enough 
information for service managers to start planning their transition. 
Some hosts will never be upgraded and will need to be phased out or 
configured with reduced connectivity. A lead time of 10 years (or 
more) will help to take good long term technical decisions and ease 
financial and organisational constraints. 


Transition and deployment 


Transition requires intimate knowledge of the environment (financial, 
political as well as technical). The task needs to be broken down so 
that service managers close to their clients can take decisions and 
make them happen. 


Let the service managers adapt the solutions for their environment by 
providing them with a transition toolbox and scenarios of their uses 
based on real examples. Clearly state the merits and limitations of 
different transition strategies. 


Provide for transition autonomy. Let systems and sites transition at 
different times, as convenient for them. 


Identify what software needs to be changed and keep an up-to-date 
listy 


Identify what is essential to have in place so that service managers 
can transition at their own pace. 


Allow for a feedback loop to improve software based on experience. 
Configuration, Administration, Operation 


We run IP on a wide range of equipment and operating systems. We 
need an easy way to (re-)configure all our IP capable systems. The 
systems need to be sent their IP parameters (e.g., their address, 
address of their default router, address of their local name servers) 
and we need to obtain data from the system (e.g., contact information 
for owner, location and name of system). We also need an easy way to 
update DNS. 


In our environment systems are regularly moved between buildings and 
we therefore find the tight coupling of IP address to physical subnet 
over restrictive. Automatic configuration could help overcome this. 


We would like to efficiently load balance users of various IP based 


services (e.g., telnet, ftp, locally written applications) across a 
number of systems. 
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The ability to break down addresses and routing into several levels 
of hierarchy is important to allow the delegation of network 
management into subdomains. As the network grows so does the desire 
to increase the number of levels of hierarchy. 


Disclaimer and acknowledgments 


This is a personal view and does not necessarily represent that of my 
employer. I have benefited from many transition discussions with my 
colleagues at CERN, other High Energy Physics DECnet managers and 
Digital Equipment Corporation engineers. 


Security Considerations 
Security issues are not discussed in this memo. 
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